Hey, thanks for pulling this together! I made a couple of comments, but barring those it looks good to me. @christopherthielen Any comments?

I like the effort to reuse the existing ui-sref code for ui-sref-active, (hopefully that works). I'll have to play with this for a while before I can comment on the implementation.

Hmph. No sauce. evaluating the full array will always return undefined.

I can think of a couple of ways to achieve the expected result and move away from concatenation:

  return [scope.$eval(attrs.uiState), scope.$eval(attrs.uiStateParams), scope.$eval(attrs.uiStateOpts)];

  return [scope[attrs.uiState], scope[attrs.uiStateParams], scope[attrs.uiStateOpts]];

  return [attrs.uiState, attrs.uiStateParams, attrs.uiStateOpts].map(function (prop) {
    return scope.$eval(prop);
  });  

thoughts?

Hmph. No sauce. evaluating the full array will always return undefined.

Yeah, I just realized I was looking at it wrong... hmm...

I can think of a couple of ways to achieve the expected result and move away from concatenation:

I'm not so much worried about the syntax as I am about the performance. Trying to think of how we can get it down to one $watch() / $eval(). Those are going to add up really quickly. I wonder if attrs.$observe() would be any cheaper...

I'll test it out when I have time, unless you beat me to it.

I'll see if I can come up with some way of cutting it down to a single $eval, not sure what that would look like though.

Regarding attrs.$observe vs scope.$watch - I do believe that the former is slightly faster, but I'm not 100% on that one. In any case I think the difference would be negligible, it's the amount of $eval's that are worrying.

Reverted back to using 3x $eval, so as to get a passing build. Still haven't figured out a better way to evaluate the three values without three consecutive calls to $eval or $parse (albeit I haven't worked on this full time...).

Unfortunately I have still not been able to figure out a way to run a single $eval call for three separate expressions - without parsing possible objects into JSON and then concatenating the strings.

I did clean up the code ever so slightly in the $watch fn expression from:

return [
  scope.$eval(attrs.uiState),
  scope.$eval(attrs.uiStateParams),
  scope.$eval(attrs.uiStateOpts)
];

Into:

return [
  attrs.uiState,
  attrs.uiStateParams,
  attrs.uiStateOpts
].map(scope.$eval.bind(scope));

Opted for angular.bind so as to get a passing spec on TravisCI (all passing locally with fn.proto.bind running karma integrate).

One could argue that it "helps" with ES5+IE8, but that is sort of moot seeing as how .map is being utilised.

@nateabele @christopherthielen - What are your thoughts on the current state of things in this PR? Have you gotten a chance to play around with it?

Personally, I will probably never use ui-state (it was always just about building it for me), so I'm not in a rush. Though I have been receiving some questions as to the status of the PR and when a possible merge would occur - I'm sort of at a loss on what to respond with (barring the ah, just +1 it friend).

I do share your concern in regards to multiple calls to $eval, and I have yet (read to test out the $attrs.observe approach. Even so I'm not crystal clear on how one would measure the possible difference in performance, any and all help in figuring that one out would be very appreciated.

Refactored this into #2187.

Closing this in favour of #2187.